AWS ParallelCluster 3.4 で有効化できるプレイスメントグループの仕様を確認してみた

大村保貴

2023.01.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS ParallelCluster 3.4 のプレイスメントグループ有効設定について調べる機会がありました。クラスターのコンピュートノードの設計時に考慮する必要がありましたので確認した結果を共有します。

ことのはじまり

AWS ParallelCluster 3.4.0 のリリースで追加された機能にコンピュートノードのマルチ AZ 起動がサポートされました。

AWS ParallelCluster のベストプラクティスにもあるように HPC ワークロードではネットワークパフォーマンスが重要視されています。

Best practices - AWS ParallelCluster

プレイスメントグループの利用を検討することになるのです、v3.4.0 リリース時点ではコンピュートノードをマルチ AZ 起動設定にするとプレイスメントグループの有効化ができませんでした。クラスタープレイスメントグループ以外の有効化方法がないか、ParallelCluster のプレイスメントグループ設定について調査することになりました。

確認結果

ParallelCluster のバージョンは3.4.0で検証した結果です。

コンピュートノードをマルチ AZ 起動時はプレイスメントグループ有効化できない
既存のパーティションプレイスメントグループを指定しても同様に設定不可であった

調べてみた

ParallelCluster 3.4.0 を用いて検証しています。

検証で使用したクラスターコンフィグ全文は長いため折りたたみます。

折りたたみ

Region: ap-northeast-1
Image:
  Os: ubuntu2004
Tags:
  - Key: Name
    Value: TestPlacementGroupCluster
# ----------------------------------------------------------------
# Head Node Settings
# ----------------------------------------------------------------
HeadNode:
  InstanceType: t3.micro
  Networking:
    ElasticIp: false
    SubnetId: subnet-035be95eeaa091603
  Ssh:
    KeyName: sandbox-key
  LocalStorage:
    RootVolume:
      Size: 35
      Encrypted: true
      VolumeType: gp3
      Iops: 3000
      Throughput: 125
  Iam:
    AdditionalIamPolicies:
      - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
    S3Access:
      - BucketName: hpc-dev-postinstall-files
        EnableWriteAccess: false
# ----------------------------------------------------------------
# Compute Node Settings
# ----------------------------------------------------------------
Scheduling:
  Scheduler: slurm
  SlurmSettings:
    ScaledownIdletime: 5
  SlurmQueues:
    # ------ Compute 1 ------
    - Name: queue-1
      ComputeResources:
        - Name: multiaz-queue
          Instances:
            - InstanceType: c6i.large
          MinCount: 0
          MaxCount: 10
          DisableSimultaneousMultithreading: true
      ComputeSettings:
        LocalStorage:
          RootVolume:
            Size: 35
            Encrypted: true
            VolumeType: gp3
            Iops: 3000
            Throughput: 125
      CapacityType: SPOT
      AllocationStrategy: lowest-price
      Networking:
        SubnetIds:
          - subnet-035be95eeaa091603
          # - subnet-0ba7369f9caba6f93
        PlacementGroup:
          Enabled: true
          Id: my-partition-placement-groups
      # CustomActions:
      #   OnNodeConfigured:
      #     Script: s3://hpc-dev-postinstall-files/sample-ubuntu-docker/postinstall.sh
      Iam:
        AdditionalIamPolicies:
          - Policy: arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
        S3Access:
          - BucketName: hpc-dev-postinstall-files
            EnableWriteAccess: false

# ----------------------------------------------------------------
# Shared Storage Settings
# ----------------------------------------------------------------
# SharedStorage:
#   - MountDir: /mnt/efs-1zone
#     Name: efs-1zone
#     StorageType: Efs
#     EfsSettings:
#       FileSystemId: fs-0f1158ade79354809
# ----------------------------------------------------------------
#  Other Settings
# ----------------------------------------------------------------
Monitoring:
  Logs:
    CloudWatch:
      Enabled: true
      RetentionInDays: 30
      DeletionPolicy: "Delete"
  Dashboards:
    CloudWatch:
      Enabled: false

プレイスメントグループについて

3種類の戦略があり利用用途に応じて使い分けします。

クラスタープレイスメントグループ
パーティションプレイスメントグループ
スプレッドプレイスメントグループ

以下のリンクで詳しく説明されていますのでご参照ください。

戦略のメリット・デメリット

ParallelCluster でプレイスメントグループを利用する前提で簡単にまとめました。

戦略	クラスター	パーティション	スプレッド
主な用途	HPC	HDFS, HBase, Casandra, Kafka, Aerospike など	各インスタンスを独自のネットワークおよび電源がある異なるラックに別々に配置
マルチ AZ 利用	✕	○	○
メリット	ノード間通信で低レイテンシー、高スループットのパフォーマンスを実現	物理ラック単位で複数のパーティションを作成し、パーティション内でノードを起動。アプリケーション内でのハードウェア障害の影響を隔離	物理ラック単位でノードを起動。ハードウェア障害による影響を隔離。ラック単位で分離しておく必要があるアプリケーションに推奨
デメリット	複数台起動をリクエスト時にキャパシティ不足で起動できない可能性が高くなる。利用可能なインスタンスタイプに制限あり（T系利用不可など）	同じパーティション内で複数台起動をリクエスト時にキャパシティ不足で起動できない可能性が高くなる。	リクエストを満たす分のハードウェアキャパシティ不足で起動できない可能性が高くなる。

ParallelCluster の仕様確認

プレイスメントグループを有効にするにはクラスターのコンフィグでPlacementGroup:をEnabled: trueと指定します。オプショナルな項目で未指定の場合、プレイスメントグループは作成されません。

      Networking:
        SubnetIds:
          - subnet-035be95eeaa091603
        PlacementGroup:
          Enabled: true

Scheduling section - AWS ParallelCluster

ParallelCluster でプレイスメントグループを有効化するとどの戦略が使われるのでしょうか？

正解はクラスタープレイスメントグループです。クラスター作成時にプレイスメントグループが新規作成されコンピュートノードで利用されます。

また v3.3.0 リリース時に仕様変更があり、旧来はキュー単位でひとつのクラスタープレイスメントグループが利用されていました。v3.3.0 以降はコンピュートリソース単位でプレイスメントグループが利用されるように改善されています。キャパシティ不足によるノード起動失敗確率を下げるために有効ですね。

Starting with AWS ParallelCluster version 3.3.0, placement group creation and management is modified. When you specify the placement group to be enabled, without a name or Id, in the queue, each compute resource is assigned its own managed placement group, instead of one managed group for the entire queue. This helps to reduce insufficient capacity errors. If you need to have one placement group for the entire queue, you can use a named placement group.

Best practices - AWS ParallelCluster

私が確認できている範囲ですと同じインスタンスタイプのときは同じプレイスメントグループが利用され、以前との変化を確認できていません。v3.3.0 で他のインスタンスタイプを混在ができるようになったため、混在時の挙動は改めて検証してみたいと思っています。

マルチ AZ 指定時のプレイスメントグループはどうなるのか？

コンピュートノードをマルチ AZ 起動指定 + プレイスメントグループ設定有効のクラスターコンフィグを作成しドライラン（--dry-run true）しました。結果 ParallelCluster はクラスター戦略のプレイスメントグループのみしか作成できないためかクラスター作成はエラーで失敗します。

{
  "configurationValidationErrors": [
    {
      "level": "ERROR",
      "type": "MultiAzPlacementGroupValidator",
      "message": "You have enabled PlacementGroups for the 'multiaz-queue' Compute Resource on the 'queue-1' queue. PlacementGroups are not supported across Availability zones. Either remove the PlacementGroup configuration to use multiple subnets on the queue or specify only one subnet to use a PlacementGroup for compute resources."
    }
  ],
  "message": "Invalid cluster configuration."
}

事前にパーティションプレイスメントグループを作成した場合は？

プレイスメントグループを事前に作成しておき、クラスターコンフィグでプレイスメントグループ名を指定すると既存のプレイスメントグループをコンピュートノードに適用ができます。その設定を使って試してみます。

事前にパーティションプレイスメントグループを作成しました。

クラスターコンフィグでプレイスメントグループ名を明示的に指定します。

      Networking:
        SubnetIds:
          - subnet-035be95eeaa091603
          - subnet-0ba7369f9caba6f93
        PlacementGroup:
          Enabled: true
          Id: my-partition-placement-groups

ドライランの結果は同じエラーでクラスターの作成に失敗します。マルチ AZ 指定の場合はプレイスメントグループを有効化できないと結論づけます。

{
  "configurationValidationErrors": [
    {
      "level": "ERROR",
      "type": "MultiAzPlacementGroupValidator",
      "message": "You have enabled PlacementGroups for the 'multiaz-queue' Compute Resource on the 'queue-1' queue. PlacementGroups are not supported across Availability zones. Either remove the PlacementGroup configuration to use multiple subnets on the queue or specify only one subnet to use a PlacementGroup for compute resources."
    }
  ],
  "message": "Invalid cluster configuration."
}

シングル AZ 指定で既存プレイスメントグループは問題ないのか？

マルチ AZ 指定でエラーになりましたが、既存プレイスメントグループを指定の設定はシングル AZ でも試したことありませんでした。動作確認してみます。

サブネットはひとつだけ指定してシングル AZ 起動にしました。

      Networking:
        SubnetIds:
          - subnet-035be95eeaa091603
          # - subnet-0ba7369f9caba6f93
        PlacementGroup:
          Enabled: true
          Id: my-partition-placement-groups

クラスターを正常に作成でき、テストジョブをサブミットしてコンピュートノードを2台起動させました。

コンピュートノードは同じ AZ だけどパーティション違いで起動してきました。パーティションプレイスメントグループのパーティションは3指定で作成していました。パーティション戦略はならべく分散して起動（ベストエフォート）することになっているため期待どおりの動作です。AZ が分散していないのは別の設定クラスター項目の配置戦略（AllocationStrategy: lowest-price）を価格優先にしている影響かと思われます。